In a basic database client/server arrangement, one or more database clients can make queries via a network to a back-end database server. The database server executes the queries and returns results to the client that requested them. The clients might be, for example, web servers or application servers or a mix of both. Typically all the clients transmit their queries to a common IP address and port number combination on the database server, and the database server transmits its results back to the IP address that originated each query. Usually an authentication process precedes the queries, in which the client provides the database server with authentication credentials (such as a username and password) and the database server establishes a “connection” through which the client can make its queries. A database server in this basic arrangement is often a single computer system, though in some implementations it might actually be a cluster of computer systems. Even such a cluster, however, is arranged so as to appear to the client as a single server reached via a single IP address and port number combination.
When client applications need to access data from the database servers, database connections are created to let the application query the database for the same. When a connection is requested, the database server has to be first located, mode of communication established and then information exchanged. In many cases the connection also needs to be authenticated, which can involve significant compute-intensive cryptographic calculations taking place at both the client system and the database server. For many data-intensive applications, the need to repeatedly make connections becomes a bottleneck. The problem is compounded because in many traditional database client/server arrangements, a client might make only one or a few queries through a connection to the database server, before it tears down the connection. In addition, if a client application tries to make a new connection at a time when the maximum number of connections possible for a database server has already been reached, a database connection failure occurs causing subsequent connections and queries to be dropped.
Many more sophisticated kinds of client/server database arrangements support the concept of connection pooling. Typically these arrangements involve the client system creating connections from a particular client system to the database servers on demand, but keeping them open when the application would otherwise close them. A pool of connections is thereby created. Thereafter, when the application requires a new connection, it is supplied from the pool if one is available, or a new connection is created if not. If the maximum number of available connections to the database server have already been made, then the connection request can be put on hold until a connection becomes available.
On the other hand, many less sophisticated kinds of client/server database arrangements do not support connection pooling. It is the task of the application developer to provide this feature. Pre-written software modules are available for implementing connection pooling in an application, but inserting them into existing application software typically requires extensive modifications in other modules in the application. Modifying an application which is not built to support connection pooling can be expensive, and time consuming, and in some cases may require significant re-engineering of its underlying structure, rendering it incompatible with future updates to the original application. Closed source applications that do not support code editing are not even capable of being modified to handle the required connection pooling.
Thus Applicants have recognized a need for a mechanism which can accelerate client/server database access, and do so transparently without requiring modification of software code in either the client application or the database servers.